Amaya's recent loss reminds me of all the little friends I had when growing up. Mr. Nitty, Roo, Minette, Scuffy, Scit-Scit, Noisette and Mr. Bean. Mr. Nitty, Roo and Minette died of old age. Scuffy, Scit-Scit and Noisette were all Burmese and all had congenital heart defects. We suspect some inbreeding there, but they were all amazing cats. Mr. Bean got hit by a car. That was rough. He was a real sweetheart, and I was playing with him maybe 10 minutes before he was killed. Luckily my parents current cats, Fuji, Moxie and Mr. Bigglesworth are doing well. I also miss Doogie and Scuba, the cats I had with my ex-girlfriend. Scuba especially was just so full of life and affection. Losing little friends is always awful.

Packages have been built backporting the security fixes from 1.0.8 into sarge's package. This package has gone to the security team and there should be a DSA soon. All the fixes were backported throught the tireless efforts of Alexander Sack. If anyone sees him, buy him a beverage. In other news, the 1.0.8 release is the end of life for the 1.0.x series. With etch at least 8 months away (wouldn't it be great if we released etch in 8 months?) doing security releases for firefox will likely increase in pain.

(aside: I love acronyms) The GFDL GR is particularly painful for packagers of GNU software like, say, automake. While I voted for it, and I think it was the right thing, it's almost physically painful to have to split my package apart for such ridiculously trivial 3 lines of Front and Back Cover Text:

     Permission is granted to copy, distribute and/or modify this
     document under the terms of the GNU Free Documentation License,
     Version 1.2 or any later version published by the Free Software
     Foundation; with no Invariant Sections, with the Front-Cover texts
     being "A GNU Manual," and with the Back-Cover Texts as in (a)
     below.  A copy of the license is included in the section entitled
     "GNU Free Documentation License."
     (a) The FSF's Back-Cover Text is: "You have freedom to copy and
     modify this GNU Manual, like GNU software.  Copies published by
     the Free Software Foundation raise funds for GNU development."

---

New DPL Anthony Towns has started his term, guns blazing. I like his idea. Making it easier to contribute to Debian can only really be a net win. The obvious objection is that this will allow untrusted people to upload to Debian. But does the current New Maintainer process really guarantee that an applicant is not malicious? I don't think so. It only weeds out impatient attackers, not determined ones. Now, if we really do believe that it is too dangerous to allow these "Debian Maintainers" direct upload, their uploads could go into their own queue. A queue that would be viewable by any "Debian Developer" to vet the package and approve it. I believe the Fedora Extras project does something similar.

From the changelog of cdbs 0.4.37:

  * Automatically add --dbg-package to dh_strip if one debug package is
    defined and debhelper level 5 is used (buildvars.mk, debhelper.mk)
    (closes: #228044); test case in debhelper-2.sh

So now adding a -dbg package is even easier now if you use cdbs. Just add the -dbg package to your control file and build depend on cdbs >= 0.4.37.

Living with mricon I get exposed to the way the other half lives. One thing I've noticed is that the RPM tools automatically build extra -debuginfo packages that contain the debugging symbols for the binaries in the package, which gdb can use. I thought too myself "That's cool, why doesn't Debian do that?" Of course, after some research it's actually very easy to accomplish the same thing in a DEB. First step is just to add a dbg package to your debian/control file like so:

Package: giblib1-dbg
Architecture: any
Section: libdevel
Priority: extra
Depends: giblib1 (= $ Source-Version )
Description: debugging symbols for giblib1
 giblib is a library of handy stuff. Contains an imlib2 wrapper to avoid the
 context stuff, doubly-linked lists and font styles.
 .
 This package contains the debugging symbols for giblib1.

Then change your call to dh_strip in your debian/rules files so it looks like this:

dh_strip --dbg-package=giblib1-dbg

If you use cdbs then just add the line:

DEB_DH_STRIP_ARGS := --dbg-package=giblib1-dbg

These cause dh_strip to place the debugging symbols under /usr/lib/debug in the named package. Make sure you have debhelper compatibility level set to 5, as the semantics for the --dbg-package switch in 4 and earlier were different and weird. So add a -dbg package to your library or binary today!

Lars Wirzenius writes that he doesn't like watch files. While it's hard to to argue against laziness (best you can do is probably: "Your mother told you not to be lazy!"), I'll try to address the other concerns. While coolness is almost always a reason in itself to do something, I think there are legitimate reasons to do it. While it may not be the case for you, I certainly think they will come in handy to help me notice new versions of some of the smaller, low-key packages I maintain (the ones without mailing lists, etc). It will be useful for statistical purposes. If enough maintainers put watch files into their packages well be able to easily see how close Debian is to the latest upstream releases. I can't argue that a more collaborative wiki-esque wouldn't be great. But we have this system and it works. I don't think the burden of having to change it if the location changes is much of a problem. It shouldn't really be an often occurrence and the copyright file would probably need to be updated at the same anyway. The ideal would be a system that combines the watch file mechaism with some sort of collaborative site.

Lars Wirzenius writes that he doesn't like watch files. While it's hard to to argue against laziness (best you can do is probably: "Your mother told you not to be lazy!"), I'll try to address the other concerns. While coolness is almost always a reason in itself to do something, I think there are legitimate reasons to do it. While it may not be the case for you, I certainly think they will come in handy to help me notice new versions of some of the smaller, low-key packages I maintain (the ones without mailing lists, etc). It will be useful for statistical purposes. If enough maintainers put watch files into their packages well be able to easily see how close Debian is to the latest upstream releases. I can't argue that a more collaborative wiki-esque wouldn't be great. But we have this system and it works. I don't think the burden of having to change it if the location changes is much of a problem. It shouldn't really be an often occurrence and the copyright file would probably need to be updated at the same anyway. The ideal would be a system that combines the watch file mechaism with some sort of collaborative site.

Eric Dorland writes about watch files, which are a way to keep track of whether there are new upstream versions of a package. He urges everyone to add them to their packages. I don't want to do that. First, I'm also the upstream of most of my packages, so my need of them is small. When I'm not upstream, I keep track of what upstream does anyway, so I'm informed of new releases that way. I realize that watch files are not useful only for the package maintainer, but also other interested parties, but, hey, I'm lazy, so I need some incentive apart from "some people think they're cool" before I take on a duty to maintain yet another aspect related to packaging. Second, I don't think watch files belong in the package. If upstream moves to a new domain, for example, the watch file needs to be updated. If it is in the package, that needs the package needs to be updated. I'd rather see watch files kept in a central server so that the package doesn't need to be changed in this situation. This would also avoid the need of having the package maintainer co-operate. Thus, I propose that those seriously interested in watch files create a "watch.debian.net" service, which keeps watch files in a centralized location, and allows them to be maintained in a wiki-like fashion.

I spent some time yesterday putting watch files in most of my packages. Watch files have been around for a long time in Debian, but hasn't reached the exposure it perhaps deserve. They're used by uscan to check for newer upstream versions of the source. What's even more useful than running uscan is the Debian Watch Health Status pages (which are also helpfully linked from the QA developer's page, but that functionality appears to be broken at the moment) which parse the watch files as well and provide a nice web interface to look up your packages and others and see where upstream is at. Unfortunately, for this to work properly the package needs a watch file, and according to the statistics, only ¹/₃ of all packages have watch files. So here's a quick tutorial, just plop a suitably modified version of these examples into the debian/watch file in your package and you're off to the races. If you're packaging foo and the source tarballs are on ftp.foo.org your watch file will look something like this:

version=3
ftp://ftp.foo.org/pub/foo/foo-(.*)\.tar\.gz

Some things to note: the version line is just there to allow for future enhancements without breaking backwards compatibility. For the location specifier, the last part after the final / is a regular expression (notice the .'s are escaped). The pattern inside the parentheses is what gets parsed as the upstream version number. For HTTP the syntax is almost identical:

version=3
http://www.foo.org/files/foo-(.*)\.tar\.gz

This snippet will download http://www.foo.org/files/ and look for href's corresponding to the rest of the pattern. For projects hosted on Sourceforge, there's a handy syntax for that, and uscan will take care of figuring out its annoying mirror system. If it's project bar, and the source is called libbar:

version=3
http://sf.net/bar/libbar-(.*)\.tar\.gz

There are many more details in the uscan man page. I think it would be great if more maintainers put watch files in their packages. It's one of those touches that really sets Debian apart from the rest.

It's maybe a little fashionable to use terms like "information overload" and that all our technology is making us less productive. I'm starting to buy into this theory a little more though. I'm having a lot of trouble keeping myself focused on any one task for an extended period of time. I constantly jump between task A to task B to check email C, making a little progress here and there, but I think I'm hurting myself with all these context switches. I can't seem to stop myself anytime I have to wait for something (even very briefly), my focus switches to something else.

The most problems are at work. Now I'm fairly sure the environment has a lot to do with it. It's an open concept type, with a few cubicle walls here and there. People are constantly interrupting me with questions and random conversations can break out frequently. For the most part I really like these aspects, but it can be very hard to concentrate on a task. Home isn't much better though. I have trouble just concentrating on one task, I almost always have a movie or TV going at the same time, and I can't seem to turn it off.

I also have so many half finished projects and good ideas (or so I'd like to believe) that I never get around to getting anywhere with out. I'm really enjoying my classes, but I don't put in the time I should to improve (I'm jealous of mricon's dedication to ).

Do other people feel like this? Does anyone have tips to better allow one to concentrate on a single task at a time, and better follow through on tasks? I mean there are some obvious things I should be doing, but I'm having trouble with those even. Outside the box ideas?

Even though I didn't make it over to Japan this year, this guy's editorial still crack me up. You may of seen it before, but he hasn't stopped.

So I'm all booked up for DebConf. I felt very put out about missing all the sauna fun last year, so I made sure not to miss this time around. I wonder if there are sauna's in Mexico, or are they rather redundant.

So to all my Canadians friends, especially mricon, who have to stay here while I'm in Mexico for a week: So long suckers!

Martin F. Krafft writes about Firefox's un-UNIX-like behavior. I mostly agree with him. Aside from the X forwarding bug in the remote implementation (which has been reported numerous times already), the main problem is the inconsistency in the interface. If I run firefox from the command line everything works fine and it behaves like a normal UNIX application (ie taking over the terminal unless I background it). If I go to another terminal and run firefox file:///tmp/foo.html, this will open a new window or tab in Firefox and immediately exits. This is very un-UNIX-like, there's no way to know if the program is actually exiting or if it's just launching a new window. These leads to fun bugs with programs that call firefox as an external viewer (see #278990 and #284174). If running firefox causes it to connect to an already running instance, it should wait(2) on that process, since that would make a lot more sense from the UNIX perspective (and perhaps a -remote flag to have the "fire-and-forget" functionality we have now, because that does make sense in some situations too).

As far as I'm concerned the whole profile mechanism is a waste of code and a hold over from the old Netscape days, for people without multiuser systems. It should be dropped completely. Although we'd probably need to be able to run multiple Firefox processes on the same profile before it could be stripped out.

There is definitely a strong Windows mentality that pervades Firefox. I still remember when the extension mechanism was first introduced back in 0.9 and you needed to run as root (or the Administrator under Windows) for it to work properly. Madness. Although UNIX does seem to be more suited to an environment where processes are lightweight and short-lived. Big, monolithic applications are a more recent phenomenon.

I've just uploaded firefox 1.5.0.1-1 to unstable, it contains a whole bunch of fixes, quite a few from my Ubuntu counterpart Ian Jackson. I can only hope that it continues like this, it will mean good things for Firefox in Debian. I also spent way too much time on Sunday doing routine bug triage, cleaning out old junk, etc. We're under 300 bugs now! Which is still a depressingly high number, but is more manageable and probably unavoidable with such a popular package. Just hope it never gets above 300 again.

I've always seen the relationship between users and developers in the Free Software world as fluid and more of a partnership. That means trying your best to fix problems yourself, and if you can't, make it as easy as possible for other people to fix it. Here's an example of a bug that isn't helpful:

The user tried to install
http://ftp.mozilla.org/pub/mozilla.org/extensions/sage/sage-1.3.6-fx mz.xpi
He is told he needs to edit his preferences to permit this, and given a button.
It turns out instead he needs to edit about:config, and set
xpinstall.enabled = true.
And indeed when he finally does, installation fails as it is an
invalid file or something.
One would be much more confident if there were a debian sage package.

It is not at all clear what the submitter is complaining about. Do they object to the preference setting for software installation? Is there a bug installing extensions? Or do they want sage packaged in Debian? Bug reports should make it clear what the submitter thinks the single problem is. When asked if the were really wanted an RFP bug, the response was:

Please reassign it that way if that is correct. All this is over my head.
Thanks.

If you've submitted over 1000 bugs maybe learning how the bug system works and is organized is a good idea? I'm not trying to attack Dan, but he is a good example of not being helpful.

So I've replaced my Soekris 4501 with a Linksys WRT54G (version 4). I was running OpenBSD off a flash card on it. I was using OpenBSD because i really like pf. ntefilter is fine, but I really appreciate pf's configuration file grammar (always thought it was crappy that iptables doesn't have a configuration file). And OpenBSD's security track record gives me the warm fuzzies.

The romance is over though. The the Mini-PCI 802.11b card I had inside it has never worked quite right, the bandwidth has always been wonky. More recently, it doesn't seem to handle multiple high bandwidth operations gracefully (maybe since upgrading to 3.7). So I'm running OpenWRT on this WRT54G, and it's fairly slick. It's amazing how much functionality can be packed onto 4MB of flash.

Well it turns out my complaining about GNOME removing their nice keyboard option configuration capplet, was completely wrong. It's actually a bug in libxklavier10. The capplet didn't really indicate that their was actually a problem though, it just looked like all the options had been removed, which threw me off. Also got good advice how to set this in the xorg.conf directly. Thanks everyone for the nice advice.

Eric Dorland wonders how to enable the Compose key just using XKB. Personally, I use my caps lock key for that, and using

        Option          "XkbOptions"    "compose:caps"

in /etc/X11/xorg.conf, that's easy enough. Other options are compose:ralt, compose:rwin, compose:menu and compose:rctrl.

Your Inner European is Dutch!

Open minded and tolerant. You're up for just about anything.

Funny thing is I look like that some mornings.

I wish there was a better way to handle conffile renames than the method outlined at dpkg.org. Be nice if there was a way to pressed the checksum, so the conffile handler could just be used naturally, instead of bypassing it with a bit of a hack. Makes me a bit uncomfortable to just accept the users changes without prompting him on upgrade (as would happen with this recipe). If anyone has a better idea, it would really help me with #345112. Reading Jacobo's post makes me wish I had proposed a DebConf talk, BoF, whatnot on Trademarks and Free Software, and maybe promote some better discussion than the last time this was on the mailing lists. ndusart is coming for the weekend! Haven't seen her in two months, so I'm understandably, ridiculously excited. Better lend mricon my earplugs.